Fixed income securities market model

ABSTRACT

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for facilitating financial interactions relating to fixed income securities. In one aspect, a computer-based method for facilitating a transfer of a fixed income security includes receiving an indication from a computer-based interface device that a initiating party seeks a counterparty for a financial transaction involving the transfer of the fixed income security, accessing data in an electronic database relating to a plurality of potential counterparties for the financial transaction and assigning to one or more of the plurality of potential counterparties an indication as to likelihood that the potential counterparty will engage in the financial transaction. The indication of likelihood that the potential counterparty will engage in the financial transaction is based on the data in the electronic database.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. §§119(e), 120 or 121of U.S. Patent Application No. 61/416,165, filed Nov. 22, 2010, and U.S.patent application Ser. No. 13/303,077 filed Nov. 22, 2011, thedisclosures of both are incorporated by reference herein in itsentirety. This application is a divisional of application Ser. No.13/303,027, the disclosure of which is incorporated herein by reference.

FIELD OF THE DISCLOSURE

This disclosure relates generally to fixed income securities, and moreparticularly to a market model for the trading of fixed incomesecurities.

BACKGROUND

Unlike equity securities, most fixed income securities (e.g., bonds) arecurrently bought and sold in the over the counter (OTC) market. The OTCmarket generally comprises securities firms and banks that trade fixedincome securities either by phone or electronically. Some firms andbanks act as dealers who keep an inventory, and buy and sell securitiesfor their own account. Others act as brokers and buy from or sell toother dealers in response to specific requests for liquidity on behalfof their customers. As such, the current fixed income security modelconsists of manual, person-to-person exchanges in two different markets.The first market is the dealer to dealer market. The second market isthe dealer to customer market. The first market generally trades withhigher transparency than the second market, and with tighter bid offerspreads. The second market generally trades with lower transparency andwider bid-offer spreads.

SUMMARY

This specification describes technologies relating to a fixed incomemarket model, including systems that can be used to implement the model.

In general, one innovative aspect of the subject matter described inthis specification can be embodied in methods that include the actionsof: receiving an indication from a computer-based interface device thatan initiating party seeks a counterparty for a financial transactioninvolving the transfer of the fixed income security, accessing data inan electronic database relating to a plurality of potentialcounterparties for the financial transaction and assigning to one ormore of the plurality of potential counterparties an indication as tothe likelihood that the potential counterparty will engage in thefinancial transaction. The indication of likelihood that the potentialcounterparty will engage in the financial transaction is based on thedata in the electronic database.

Other embodiments of this aspect include corresponding systems,apparatus, and computer programs, configured to perform the actions ofthe methods, encoded on computer storage devices.

In some implementations, the method includes ranking the potentialcounterparties based on the indication of likelihood assigned to eachrespective one of the potential counterparties. Moreover, someimplementations include enabling the initiating party to view at acomputer-based interface device one or both of: the assigned indicationsof likelihood that the respective potential counterparties will engagein the financial transaction; and the rankings of each potentialcounterparty based in the assigned indications of likelihood.

According to certain embodiments, the method includes enabling theinitiating party to enter a request at the computer-based interfacedevice that a Request For Quote (RFQ) be sent to a specified one or morepotential counterparties identified by the initiating party to enterinto the financial transaction. Still other embodiments include sendingan inquiry over a computer network as to actual interest inparticipating in the financial transaction to: each of the specified oneor more of potential counterparties, if any, and one or more of thepotential counterparties with the highest assigned indication oflikelihood that the potential counterparty will engage in the financialtransaction. Sending the inquiries may be accomplished in a manner thatdoes not reveal the identity of the initiating party.

In some implementations, the method includes receiving one or moreresponses to the inquiries sent from one or more of the potentialcounterparties; and enabling the initiating party to access informationabout the one or more responses at the computer-based interface. In someof such implementations, enabling the initiating party to access theinformation is accomplished without revealing the identities of theresponding potential counterparties.

In a typical implementation, multiple responses are received and thecomputer-based method includes combining two or more of the responses tocreate a single offer that satisfies requirements associated withcompleting the financial transaction based on information provided bythe initiating party. The method can further include enabling theinitiating party to view information about the single offer at thecomputer-based interface device. Moreover, the method can includeenabling the potential counterparties, in responding to the inquiries,to specify an expiration time for an offer contained in their response.

At least one of the responses combined to create the single offer mayhave a specified expiration time and the information about the singleoffer changes upon expiration of the specified expiration time.

In some implementations, assigning to each respective one of thepotential counterparties an indication of likelihood that the potentialcounterparty will engage in the financial transaction can include:determining, based on the data in the electronic database, one or moreof the following: to what degree the potential counterparty is involvedin current bids related to the fixed income security, to what degree thepotential counterparty was involved in past bids related to the fixedincome security, to what degree the potential counterparty was involvedin completed transactions related to the fixed income security, to whatdegree the potential counterparty has expressed an interest related tothe fixed income security, and to what degree the potential counterpartyhas portfolio holdings related to the fixed income security.

Assigning to each respective one of the plurality of potentialcounterparties an indication of likelihood that the potentialcounterparty will engage in the financial transaction can include:determining, based on the data in the electronic database, to whatdegree the potential counterparty is or was on the opposite side ofother transactions from the side of the transaction desired.

Determining to what degree the potential counterparty is involved incurrent bids related to the fixed income security can includedetermining, based on the data in the electronic database, one or moreof the following: to what degree the potential counterparty is involvedin current bids for the fixed income security, to what degree thepotential counterparty is involved in current bids for different fixedincome securities with the same issuer as the fixed income security, towhat degree the potential counterparty is involved in current bids fordifferent fixed income securities in the same industry as the fixedincome security, to what degree the potential counterparty is involvedin current bids for different fixed income securities in the samematurity bracket as the fixed income security, to what degree thepotential counterparty is involved in current bids for different fixedincome securities with the same rating as the fixed income security, andto what degree the potential counterparty is involved in current bidsfor different fixed income securities with the same yield percentage asthe fixed income security.

Determining to what degree the potential counterparty was involved inpast bids related to the fixed income security can include determining,based on the data in the electronic database, one or more of thefollowing: to what degree the potential counterparty was involved inpast bids for the fixed income security, to what degree the potentialcounterparty was involved in past bids for different fixed incomesecurities with the same issuer as the fixed income security, to whatdegree the potential counterparty was involved in past bids fordifferent fixed income securities in the same industry as the fixedincome security, to what degree the potential counterparty was involvedin past bids for different fixed income securities in the same maturitybracket as the fixed income security, to what degree the potentialcounterparty was involved in past bids for different fixed incomesecurities with the same rating as the fixed income security, and towhat degree the potential counterparty was involved in past bids fordifferent fixed income securities with the same yield percentage as thefixed income security.

Determining to what degree the potential counterparty was involved incompleted transactions related to the fixed income security can include:determining, based on the data in the electronic database, one or moreof the following: to what degree the potential counterparty hascompleted transactions including the fixed income security, to whatdegree the potential counterparty has completed transactions includingdifferent fixed income securities with the same issuer as the fixedincome security, to what degree the potential counterparty has completedtransactions including different fixed income securities in the sameindustry as the fixed income security, to what degree the potentialcounterparty has completed transactions including different fixed incomesecurities in the same maturity bracket as the fixed income security, towhat degree the potential counterparty has completed transactionsincluding different fixed income securities with the same rating as thefixed income security, and to what degree the potential counterparty hascompleted transactions including different fixed income securities withthe same yield percentage as the fixed income security.

Determining to what degree the potential counterparty has portfolioholdings related to the fixed income security can include determining,based on the data in the electronic database, one or more of thefollowing: to what degree the portfolio of the potential counterpartyincludes the fixed income security, to what degree the portfolio of thepotential counterparty includes different fixed income securities withthe same issuer as the fixed income security, to what degree theportfolio of the potential counterparty includes different fixed incomesecurities in the same industry as the fixed income security, to whatdegree the portfolio of the potential counterparty includes differentfixed income securities in the same maturity bracket as the fixed incomesecurity, to what degree the portfolio of the potential to counterpartyincludes different fixed income securities with the same rating as thefixed income security, and to what degree the portfolio of the potentialcounterparty includes different fixed income securities with the sameyield percentage as the fixed income security.

In some implementations, the method of claim 12 includes enabling theinitiating party and each of the plurality of potential counterpartiesto create respective virtual profiles, each of which can include anexpression of interest in one or more characteristics associated withfixed income securities. Assigning to each respective one of theplurality of potential counterparties the indication of likelihood thatthe potential counterparty will engage in the financial transactionfurther comprises determining to what degree a virtual profileassociated with one of the potential counterparties includes anexpression of interest related to the fixed income security.

In certain embodiments, determining to what degree the potentialcounterparty has expressed interest related to the fixed securityincludes determining, based on the data in the electronic database, oneor more of the following: to what degree the virtual profile associatedwith the potential counterparty includes an expression of interest inthe fixed income security, to what degree the virtual profile associatedwith the potential counterparty includes expressions of interest indifferent fixed income securities with the same issuer as the fixedincome security, to what degree the virtual profile associated with thepotential counterparty includes expressions of interest in differentfixed income securities in the same industry as the fixed incomesecurity, to what degree the virtual profile associated with thepotential counterparty includes expressions of interest in differentfixed income securities in the same maturity bracket as the fixed incomesecurity, to what degree the virtual profile associated with thepotential counterparty includes expressions of interest in differentfixed income securities with the same rating as the fixed incomesecurity, and to what degree the virtual profile associated with thepotential counterparty includes expressions of interest in differentfixed income securities with the same yield percentage as the fixedincome security.

The method can include automatically inquiring, over the computernetwork, to what degree a selected one of the potential counterpartieshas an interest in conducting the financial transaction. The automaticinquiry is in response to a determination, based on the data in theelectronic database, that the selected potential counterparty is or wasinvolved in a bid or completed a transaction for the fixed incomesecurity.

Some embodiments of the method include enabling the initiating party andthe potential counterparties to post and view orders at an electronicorder book that is accessible from computer terminals coupled to thecomputer network.

In another aspect, a computer system facilitates financial transactionsinvolving a transfer of a fixed income security. The computer systemincludes one or more user devices, typically computer terminals or handheld mobile computing devices and one or more computers operable tointeract via a computer network with the one or more user devices. Theone or more computers include a sales engine to receive an indicationfrom a first one of the user devices that an initiating party seeks acounterparty for the financial transaction involving the transfer of thefixed income security, a matching engine to access, in an electronicdatabase, data relating to a plurality of potential counterparties forthe financial transaction and assign to one or more of the potentialcounterparties an indication of likelihood that the potentialcounterparty will engage in the financial transaction. Each indicationof likelihood is based on the data in the electronic database.

In some implementations, the matching engine is further configured torank the potential counterparties based on the indications of likelihoodassigned to each respective one of the potential counterparties.

The one or more computers can be further adapted to enable theinitiating party to view at the first one of the user devices at leastone of: the assigned indications of likelihood that the respectivepotential counterparties will engage in the financial transaction; andthe ranking of the plurality of potential counterparties. In certainembodiments, the one or more computers are further configured to enablethe initiating party to enter a request at the first one of the userdevices that a Request For Quote (RFQ) be sent to one or more potentialcounterparties specifically identified by the initiating party to enterinto the financial transaction.

The sales engine can be further configured to send a request to: each ofthe one or more potential counterparties specifically identified by theinitiating party, if any; and one or more of the potentialcounterparties having the highest assigned indications of likelihoodthat the potential counterparty will engage in the financialtransaction. Moreover, in some implementations, the sales engine cansend the requests without revealing the initiating party's identity topotential counterparties receiving the requests.

Typically, the sales engine receives one or more responses to theinquiries sent from one or more of the potential counterparties and theone or more computers are configured to make the responses available forviewing by the initiating party at the first one of the user devices.Making the responses available for viewing by the initiating party atthe first one of the user devices can be accomplished without revealingan identity of the responding potential counterparties at the first oneof the user devices.

In some implementations, the one or more computers further include aprice aggregation engine to combine two or more of the responses tocreate a single offer that satisfies requirements associated withcompleting the financial transaction based on information provided bythe initiating party. The one or more computers can be furtherconfigured to make information about the single combined offer availablefor viewing at the first one of the user devices.

In certain embodiments, the one or more computers are further configuredto: enable the potential counterparties, in responding to the inquiries,to specify an expiration time for an offer contained in their response.At least one of the responses combined to create the single offer mayhave a specified expiration time and the information about the singleoffer may change based on the specified expiration time.

The matching engine, in assigning to each respective one of thepotential counterparties an indication of likelihood that the potentialcounterparty will engage in the financial transaction, can be configuredto determine, based on data in the electronic database, one or more ofthe following: to what degree the potential counterparty is involved incurrent bids related to the fixed income security, to what degree thepotential counterparty was involved in past bids related to the fixedincome security, to what degree the potential counterparty was involvedin completed transactions related to the fixed income security, to whatdegree the potential counterparty has expressed an interest related tothe fixed income security, and to what degree the potential counterpartyhas portfolio holdings related to the fixed income security.

The matching engine, in assigning to each respective one of thepotential counterparties an indication of likelihood that the potentialcounterparty will engage in the financial transaction, can be configuredto determine, based on the data in the electronic database, whether thepotential counterparty is or was on the opposite side of othertransactions from the side of the transaction desired.

The matching engine, in determining to what degree the potentialcounterparty is involved in current bids related to the fixed incomesecurity, can be configured to determine one or more of the following:to what degree the potential counterparty is involved in current bidsfor the fixed income security, to what degree the potential counterpartyis involved in current bids for different fixed income securities withthe same issuer as the fixed income security, to what degree thepotential counterparty is involved in current bids for different fixedincome securities in the same industry as the fixed income security, towhat degree the potential counterparty is involved in current bids fordifferent fixed income securities in the same maturity bracket as thefixed income security, to what degree the potential counterparty isinvolved in current bids for different fixed income securities with thesame rating as the fixed income security, and to what degree thepotential counterparty is involved in current bids for different fixedincome securities with the same yield percentage as the fixed incomesecurity.

The matching engine, in determining to what degree the potentialcounterparty was involved in past bids related to the fixed incomesecurity, can be configured to determine one or more of the following:to what degree the potential counterparty was involved in past bids forthe fixed income security, to what degree the potential counterparty wasinvolved in past bids for different fixed income securities with thesame issuer as the fixed income security, to what degree the potentialcounterparty was involved in past bids for different fixed incomesecurities in the same industry as the fixed income security, to whatdegree the potential counterparty was involved in past bids fordifferent fixed income securities in the same maturity bracket as thefixed income security, to what degree the potential counterparty wasinvolved in past bids for different fixed income securities with thesame rating as the fixed income security, and to what degree thepotential counterparty was involved in past bids for different fixedincome securities with the same yield percentage as the fixed incomesecurity.

The matching engine, in determining to what degree the potentialcounterparty was involved in completed transactions related to the fixedincome security, can be configured to determine one or more of thefollowing: to what degree the potential counterparty has completedtransactions including the fixed income security, to what degree thepotential counterparty has completed transactions including differentfixed income securities with the same issuer as the fixed incomesecurity, to what degree the potential counterparty has completedtransactions including different fixed income securities in the sameindustry as the fixed income security, to what degree the potentialcounterparty has completed transactions including different fixed incomesecurities in the same maturity bracket as the fixed income security, towhat degree the potential counterparty has completed transactionsincluding different fixed income securities with the same rating as thefixed income security, and to what degree the potential counterparty hascompleted transactions including different fixed income securities withthe same yield percentage as the fixed income security.

The matching engine, in determining to what degree the potentialcounterparty has expressed an interest related to the fixed incomesecurity, can be configured to determine one or more of the following:to what degree the portfolio of the potential counterparty includes thefixed income security, to what degree the portfolio of the potentialcounterparty includes different fixed income securities with the sameissuer as the fixed income security, to what degree the portfolio of thepotential counterparty includes different fixed income securities in thesame industry as the fixed income security, to what degree the portfolioof the potential counterparty includes different fixed income securitiesin the same maturity bracket as the fixed income security, to whatdegree the portfolio of the potential counterparty includes differentfixed income securities with the same rating as the fixed incomesecurity, and to what degree the portfolio of the potential counterpartyincludes different fixed income securities with the same yieldpercentage as the fixed income security.

In some implementations, the one or more computers are furtherconfigured to: enable the initiating party and each of the plurality ofpotential counterparties to create respective virtual profiles, each ofwhich can include an expression of interest in one or morecharacteristics associated with fixed income securities. Assigning toeach respective one of the plurality of potential counterparties theindication of likelihood that the potential counterparty will engage inthe financial transaction further includes determining to what degree avirtual profile associated with one of the potential counterpartiesincludes an expression of interest related to the fixed income security.

The matching engine, in assigning to each respective one of theplurality of potential counterparties an indication of likelihood thatthe potential counterparty will engage in the financial transaction, canbe configured to determine one or more of the following: to what degreethe virtual profile associated with the potential counterparty includesexpressions of interest in the fixed income security, to what degree thevirtual profile associated with the potential counterparty includesexpressions of interest in different fixed income securities with thesame issuer as the fixed income security, to what degree the virtualprofile associated with the potential counterparty includes expressionsof interest in different fixed income securities in the same industry asthe fixed income security, to what degree the virtual profile associatedwith the potential counterparty includes expressions of interest indifferent fixed income securities in the same maturity bracket as thefixed income security, to what degree the virtual profile associatedwith the potential counterparty includes expressions of interest indifferent fixed income securities with the same rating as the fixedincome security, and to what degree the virtual profile associated withthe potential counterparty includes expressions of interest in differentfixed income securities with the same yield percentage as the fixedincome security.

The sales engine, in some embodiments, is further adapted to:automatically inquire, via the computer network, to what degree aselected one of the potential counterparties wants to conduct thefinancial transaction in response to a determination, based on the datain the electronic database, that the selected potential counterparty isor was involved in a bid for the fixed income security or completed atransaction for the fixed income security.

According to certain embodiments, the one or more computers are furtherconfigured to enable the initiating party and the potentialcounterparties to post and view orders at an electronic order book thatis accessible from computer terminals coupled to the computer network.

In some implementations, the one or more user devices include one ormore of the following: a computing device running a web browser, aspreadsheet add-in, an order management system, an applicationprogramming interface, a financial information exchange program or thelike.

In yet another aspect, a computer-based method is disclosed forprocessing offers received from potential counterparties to engage in aproposed financial transaction involving a transfer of a fixed incomesecurity. The potential counterparties include one or more potentialcounterparties specifically identified by an initiating party as apotential counterparty to the financial transaction and one or morepotential counterparties selected by a computer-based matching engine asbeing likely interested in the proposed financial transaction. Thecomputer-based method includes receiving one or more offers from thepotential counterparties specifically identified by the initiatingparty, receiving one or more offers from the potential counterpartiesselected by the computer-based matching engine; and identifying, amongthe received offers, one or more of the received offers that alone orcollectively provide the initiating party a best price for a quantity ofthe fixed income security that satisfies requirements of the proposedfinancial transaction.

Certain implementations include enabling the initiating party to accessinformation about the one or more received offers that alone orcollectively provide the initiating party the best price for thequantity of the fixed income security that satisfies requirements of theproposed financial transaction. More than one of the received offers canbe combined to collectively satisfy the requirements of the proposedfinancial transaction.

In some implementations, at least one of the more than one receivedoffers combined to satisfy the requirements of the proposed financialtransaction has an associated duration, after which the offer willexpire. The information about the received offers that the initiatingparty can access is updated upon expiration of the associated durationto reflect a new best price for the quantity of fixed income securitythat satisfies requirements of the proposed financial transaction. Thesystem can receive the indication of the associated duration along withan associated one of the received offers from one of the potentialcounterparties.

In some implementations, one or more of the following advantages arepresent.

For example, participants in the fixed income securities market mayenjoy more access to helpful data about the market. Additionally, theparticipants are able to access a larger pool of liquidity than waspreviously possible. Moreover, interactions between initiating partiesand potential counterparties are greatly facilitated.

The details of one or more implementations of the subject matterdescribed in this specification are set forth in the accompanyingdrawings and the description below. Other features, aspects, andadvantages of the subject matter will become apparent from thedescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is schematic diagram representing exemplary relationships amongvarious parties in a two-tiered fixed income securities market.

FIG. 1B is a schematic representation of buyer and seller interactionsin the two-tiered fixed income securities market of FIG. 1A.

FIGS. 1C and 1D are schematic representations showing orders beingfilled in the two-tiered fixed income securities market of FIG. 1A.

FIG. 2A is schematic diagram representing exemplary relationships amongmarket participants in a single-tiered fixed income securities marketthat includes a computer-based platform to facilitate financialtransactions between the market participants.

FIG. 2B is a schematic representation of buyer and seller interactionsin the single-tiered fixed income securities market of FIG. 2A.

FIG. 2C is a schematic representation showing an order being filledusing the RFQ functionality of the single-tiered fixed income securitiesmarket of FIG. 2A.

FIG. 3 is a schematic diagram of an exemplary system that includes adetailed example of the computer-based platform in FIG. 2A.

FIG. 4 is a flowchart of an exemplary method in which the computer-basedplatform in FIG. 2A facilitates financial transactions between marketparticipants.

FIG. 5 is a flowchart of an exemplary method by which the computer-basedplatform in FIG. 2A generates a list of potential counterparties for afinancial transaction.

FIGS. 6A-6F include a flowchart of an exemplary method by which thecomputer-based platform in FIG. 2A determines the likelihood that apotential counterparty will be interested in a proposed financialtransaction involving a transfer of a fixed income security.

FIGS. 7A-7G are schematic representations of the computer-based platformof FIG. 2A facilitating a financial transaction involving a fixed incomesecurity.

FIGS. 8A-8F are exemplary screenshots of the display that an initiatingparty sees when accessing certain functionality associated with thecomputer-based platform of FIG. 2A.

DETAILED DESCRIPTION

The following is a disclosure of a fixed income market model, as well asvarious methods and systems for implementing such a model.

Overview and Fundamentals

An overview of the art is provided to assist the reader's appreciationof the context of this specification, as well as some of the problemsthat can be solved by certain implementations of systems and methodsdescribed herein.

As mentioned, the current fixed income security model consists ofmanual, person-to-person exchanges in two different markets. The firstmarket is the dealer to dealer market. Institutional investors rely onthe dealer to dealer market to (1) find or provide liquidity forsecurities, (2) locate the best price on those securities, and (3) matchbuyers and sellers to execute desired trades. When looking to transactin fixed income securities in the dealer to dealer market, investorsmust give an indication of their intention to trade (sometimes referredto as “indications of interest” or simply “IOIs”). This indication canbe given in many forms, e.g., emails, phone calls, bid lists, and axesheets. In theory, these sources combine to create a small measure ofmarket data on what are generally regarded to be relatively illiquidsecurities. As a result of the incompleteness of this market data, bysome estimates, 97% of the corporate bond market is “dark”—in general,there are no real-time prices available during the day.

Within the bond market generally, there are two ways to find liquidity:inventory based or inquiry based. Inventory based discovery is based onIOIs distributed by dealers (e.g., phone calls, emails, axe sheets,dealer runs, etc.). These IOI's indicate liquidity, but they aregenerally not executable, and since they are not updated over the courseof the day, they are not up to date.

On the other hand, inquiry based discovery is based on marketparticipants who want to trade specific securities. The party that wantsto trade generally uses a broker to find a trading partner. It isdifficult for brokers to initiate trades, especially large trades,without having the market move against them due to the amount ofliquidity they are placing on the market (e.g., pricing moving down witha large sell or prices moving up with a large buy). Additionally, a lackof transparency in the market makes it difficult for customers ofbrokers to assess the quality of execution of trades.

Market participants can only trade in the market if they know where tosearch for liquidity. For that reason, customers (e.g., investors andtheir brokers) tend to trade with dealers, who hold proprietaryinformation about where to locate liquidity. Due to this informationdisparity, dealers are able to trade with other dealers in a fairlytransparent marketplace, while customers do not have access to thatmarketplace. To trade, the customer must give up large amounts ofinformation to the dealer, which perpetuates the existing informationdisparity. This leads to the two tiered marketplace already described.

To trade large volumes, market participants (in this case, eithercustomers or dealers) must expose their order either entirely to onedealer, or to the market through multiple dealers. Information leakageis a significant issue in these situations, and the use of multipledealers causes significant increases in execution costs. Further,fragmentation of the marketplace leads to significant increases incustodial fees. Although involving more than one counterparty is oftennecessary to insure best execution (i.e., executing portions of an orderagainst multiple, smaller, better priced counterparts as opposed toexecuting a whole order against a single, larger, worse pricedcounterpart), that amplifies the effects of fragmentation in the market.This creates significant enough friction in the market that someentities have started providing services such as “single ticketclearing” to aggregate custodial fees.

The transparency in the first market (dealer to dealer) has benefitteddealers, granting them an “information arbitrage” over their customerswho must participate in the second market (dealer to customer). Part ofthis is due simply to the fact that institutional customers do not haveaccess to the existing dealer to dealer market. In reality, however,giving customers access to the dealer to dealer market would presentcustomers with a different, more fundamental set of problems that plaguethe fixed income market. Such problems include a lack of real-timemarket data and a lack of systems for (1) aggregating and presentingthat real-time market data, (2) finding liquidity without having toexpose orders to the entire market, and (3) initiating and responding totrades.

By way of illustration, FIG. 1A shows an example of a two tiermarketplace. In the illustrated marketplace, the first market 101 is amarketplace in which primary dealers 103 compete. The primary dealers103 have access to several Inter-Dealer Broker systems (IDB) 102. Theprimary dealers 103 trade with each other using the IDB systems 102 inthe first market 101. The IDB systems 102 include automated systems forposting and viewing available liquidity in the fixed income securitymarketplace, but are generally only available to dealers. The datacontained in the IDB systems 102 thus provide a limited view of thestate of the fixed income security market.

The first market 101 carries large amounts of information, with a fairlyopen flow of information between the primary dealers 103. This leads toa first market 101 that is generally more transparent and has lowerbid-ask spreads than the second market 104.

The second market 104, on the other hand, includes traditional buy sideclients 105 trading with the primary dealers 103. To trade, thetraditional buy side clients 105 generally give substantial amounts ofinformation 108 to the primary dealers 103 so that the primary dealers103 can generate quotes. Because of the information disparity that thiscreates, the second market 104 generally trades with much lowertransparency and much larger bid-ask spreads than the first market 101.

Regional dealers 106 occasionally exist between traditional buy sideclients 105 and primary dealers 103. Although the regional dealers 206may trade with each other, they generally do not have access to IDBs102, and therefore cannot access the majority of information andefficiencies produced in the first market 101. Regional dealers 106often use primary dealers 103 in order to access liquidity.

FIG. 1B is a schematic representation of the fixed income securitymarket of FIG. 1A, with buyers 105 a and sellers 105 b trying to reacheach other, but being constrained largely by first market 101(represented by the pinch point between the two sides of the bowtieshape). Within the first market 101, the primary dealers 103 use the IDBsystems 102 to deal with each other, and then transmit the securitiesfrom buyer 105 a to seller 105 b. The buyers 105 a and the sellers 105 bgive a lot of information to the primary dealers 103, but the primarydealers 103 give very little information back to them.

FIG. 1C is a schematic representation of a full order 110 (e.g., from afirst one of the market participants 105 in FIG. 1A) being split intothree separate order segments 112 a, 112 b, 112 c. This can be desirableif, for example, the full order is too large to be satisfied by a singlecounterparty. The order segments 112 a, 112 b, 112 c may be the samesize as one another or may be different sizes.

According to the illustrated implementation, each order segment 112 a,112 b, 112 c is sent to a separate one of the primary dealers 103 a, 103b, and 103 c. Each primary dealer 103 a, 103 b, 103 c exposes details ofits own order segment 112 a, 112 b, 112 c to the marketplace (including,for example, multiple buy side clients 105).

In the illustrated embodiment, each primary dealer 103 a, 103 b, 103 cseparately settles multiple sub accounts 114 to satisfy its own ordersegment 112 a, 112 b, and 112 c. More particularly, in the illustratedimplementation, each primary dealer 103 a, 103 b, 103 c separatelysettles three sub accounts 114 to satisfy its own order segment. Thisleads to nine settlements between the three different primary dealers505, each of which typically requires separate processing and payment ofassociated fees.

FIG. 1D shows an alternate scenario whereby the market participant(e.g., one of the buy side clients 105 of FIG. 1A) is willing to exposeits full order 110 to a single primary dealer 103 a.

In the illustrated scenario, the primary dealer 103 a routes the orderto multiple sub accounts 114. More particularly, the primary dealer 103a in the illustrated scenario routes the order to three different subaccounts 114. Using a single dealer for a large purchase typicallyresults in the purchaser receiving a weak price due, at least in part tointeracting with a single primary dealer, and the informationdisadvantage inherent in giving that single primary dealer all of therelevant information about the desired exchange. Additional fees arealso incurred by having to pay for processing and associated fees inconnection with the separate settlement of the different sub accounts114.

The Single Tier Fixed Income Market Model

An implementation of a single tier fixed income market model employs atrading system platform that comprises an “all-to-all” protocol,replacing the previous customer to dealer and dealer to dealermarketplaces. This market model provides for direct trading of fixedincome securities between institutional investors, brokers, and others.Trading in such a system can be automated.

FIG. 2A shows an implementation of the single tier fixed income marketmodel. The market model is implemented using a trading system platform220 (shown simplified for clarity). The system platform 220 is adaptedto support a computer-based all-to-all, request-for-quotation (“RFQ”)functionality 222 and an order book functionality 224. In general, theRFQ functionality enables users (e.g., market participants 228) torequest quotations from other users for a desired financial transactioninvolving the transfer of one or more fixed income securities. Ingeneral, the order book functionality provides each user with a listingof assets that the various users have orders posted for.

As discussed in further detail herein, the market participants 228 canaccess the system platform 220 from computer terminals, handheld mobiledevices, or the like that are coupled to the system platform 220, forexample, by a computer network, such as the Internet.

In some implementations, the RFQ functionality 222 of the systemplatform 220 can enable market participants 228 (e.g., buyers andsellers) to find counterparty buyers and sellers. Typically, thisfunctionality relates to traditionally illiquid securities, such asbonds. Additionally, the system platform 220 typically can be used bymarket participants 228 to investigate multiple bids or offers on one ormore bonds. The market participants 228 also typically can send RFQ's toone or more designated parties or can use other modules described hereinto seek out and interact with likely counterparties. Market participants228 can choose to either remain anonymous or expose themselves and/ortheir preferences to one or more of the potential counterparties.

In some implementations, the order book functionality 224 enables marketparticipants to access various trading opportunities posted by othermarket participants. This information can be presented in a variety ofways and may be searchable, sortable, etc.

FIG. 2B is a schematic representation of the fixed income securitymarket of FIG. 2A, with buyers 228 a and sellers 228 b able to dealdirectly with each other using the platform 220 as a link.

FIG. 2C is a schematic representation of the platform 220 facilitating afinancial transaction that involves the transfer of fixed incomesecurities from an initiating party to multiple counterparties 230 a,230 b, 230 c.

According to the illustrated implementation, the initiating partysubmits a full order 210, which includes all of the fixed incomesecurities that the initiating party wants to transfer, to the platform220 by accessing the platform's RFQ functionality. The full order 210 isprocessed by a sales engine and matching engine 212, which are part ofthe platform 220, to identify potential counterparties 230 a, 230 b, 230c that the matching engine determines to be most likely to engage in thefinancial transaction. The sales engine then contacts the potentialcounterparties 230 a, 230 b, 230 c identified by the matching engine.The counterparties 230 a, 230 b, 230 c return their respective offers232 a, 232 b, and 232 c.

In the illustrated example, none of the offers 232 a, 232 b, 232 c iscapable on its own of fully satisfying the requirements (e.g., to supplyenough volume) associated with the full order 210. However, the offers232 a, 232 b, 232 c can be combined to satisfy the requirementsassociated with the full order 210. The offers 232 a, 232 b, 232 c arethen processed by a price aggregation engine 234, which is part ofplatform 220, to combine them and generate the best possible singleprice for the initiating party at which the full order 210 can besatisfied.

In the illustrated example, the aggregation engine completes the order,reports it on a single ticket, and reports 236 the order to threeseparate subaccounts at the same price. When a transaction is completed,it often needs to be distributed to multiple accounts. For example, afund manager often handles multiple mutual funds. When the managercompletes a trade and distributes, the system can distribute it all atthe one aggregated price instead of the fund manager having to handlemultiple transactions, asset allocations, and fees. Note that from theperspective of the initiating party, all trades are completed at theaggregated price. The results are therefore calculated, processed, anddistributed at that price. However, from the perspective of the partiesresponding to RFQs, the trades are at the prices they proposed.Typically, this is possible due to the system, as a riskless principal,existing in between the parties.

Overview of an Example System for Implementing a Fixed Income MarketModel

To implement a single tier fixed income security market (e.g., asdescribed in FIGS. 2A to 2C), a platform 220 (e.g., a network ofcomputer devices) can facilitate communications and interactions betweenvarious market participants 228. FIG. 3 is a schematic representation ofan exemplary system 300 that includes an implementation of such aplatform 220. In general, the illustrated platform 220 is configured toimplement both RFQ functionality 222 and order book functionality 224.

In most implementations, the platform is administrated by a businessentity. In the implementation shown in FIG. 3, the portions of thesystem within box 220 would be operated by the administrator of thebusiness entity. Of course, this does not mean that the portionsoperated by the administrator must be located in the same physicallocation or that an administrator could not use a third party to assistin administering the platform 220. Elements within box 220 generallyconstitute a sales engine 362, a matching engine 364, a priceaggregation engine 366 and an electronic database 368.

The market participants 228 can interact with the platform 220 in avariety of ways. For example, the platform 220 can be accessed directlythrough the internet or a spreadsheet add-in, or through the users'order management systems (OMS) alongside an execution management system(EMS) 223. Users can communicate with the EMS 223 using several systems,including proprietary management systems and custom ApplicationProgramming Interfaces (API). Additionally, the EMS 223 can communicatewith the platform 220 using industry standard messaging, such asFinancial Information Exchange (FIX). Generally, each of the marketparticipants interacts with the platform from a remote location;accordingly, communication between market participants and the platform220 is usually accomplished using known communication means, such aswired and/or wireless networking.

The illustrated platform 220 includes a sales engine 362, a matchingengine 364 and a price aggregation engine 366, which can be implemented,for example, with hardware, software or a combination thereof. Theillustrated platform 220 also includes an electronic database 368, whichcan store various information discussed herein and various otherinformation to facilitate the platform's functionality. The platform 220has several data libraries, which may be stored in the electronicdatabase or may be stored electronically elsewhere. These include datalibraries for customer trade history 352, customer alerts 354, customersupplied data 356, system transaction data 358 and customer listedsecurities 360. In various implementations, the platform 220 includesother data libraries and/or organizes data into different datalibraries. As discussed herein, the platform 220 is generally operableto leverage the data stored in these data libraries and/or in the datastored in the electronic database 368 to support the functionalitydisclosed herein.

The platform 220 is coupled for communications with post-trade andclearing systems 342. In a typical implementation, after the platformgenerates or matches a trade, the trade is passed to these systems toprovide services associated with post-trade operations and clearing.

The platform 220 is also coupled for communications with a pricingsource 340. In some implementations, the pricing source 340 providespricing estimates to the platform 220 to help facilitate thefunctionalities discussed herein.

The platform is also coupled for communications with other parties 344,which may include, for example, data recipients/distributors 348 andregulators 350. In a typical implementation, the datarecipients/distributors may include various parties that pay to accessdata associated with the financial transactions facilitated by theplatform 220. In a typical implementation, the platform storestransactional and associated statistical data about the transactionsfacilitated by the platform 220. This and other information may bereported out to the other parties and/or used by the system itself tohelp identify preferences, for example, of various market participants228.

FIG. 4 shows exemplary interactions between a market participant (e.g.,a party seeking to initiate a financial transaction) and the platform220.

According to the illustrated method, the market participant accesses (at402) the platform, including its associated functionality. As discussedabove, this can be done in a number of ways. Typically, access is gainedfrom a computer device (i.e., a user terminal) located at the marketparticipant's physical location.

The platform 220 then enables the market participant (at 404) to choosebetween accessing either the platform's order book functionality orrequest for quotation (“RFQ”) functionality. This can be accomplished,for example, by presenting a prompt to the market participant to selectone of the functionalities or the other.

If the market participant (at 404) chooses to access the platform'sorder book functionality, then the platform 220 (at 406) enables themarket participant to access the order book functionality. In a typicalimplementation, the platform 220 does this by presenting at the marketparticipant's user interface the information associated with the orderbook functionality. For example, in response to the market participantselecting a hyperlink associated with the order book functionality, theplatform 220 may cause one or more webpages to become available forviewing at the market participant's user interface. The one or morewebpages, in that example, may include a list (or lists) of fixed incomesecurities that other market participants have listed within the orderbook as being available for purchase or sale.

The list (or lists) of fixed income securities available for purchasecan be organized and presented to the market participant in a number offormats. In a typical implementation, the market participant may browseand/or search the list (or lists) as desired and follow-up accordinglyif the market participant has an interest in purchasing a particular oneof the listed fixed income securities.

If the market participant chooses (at 404) to access the platform's RFQfunctionality, then the platform 220 enables (at 408) the marketparticipant to access the platform's RFQ functionality. In a typicalimplementation, the platform 220 does this by presenting at the marketparticipant's user interface information associated with the RFQfunctionality. For example, in response to the market participantselecting a hyperlink associated with the RFQ functionality, theplatform 220 may cause one or more webpages associated with the RFQfunctionality to become available for viewing at the marketparticipant's user interface.

In the illustrated implementation, the platform 220 (at 410) enables themarket participant to indicate whether/to what degree there are anypotential counterparties that the market participant is aware of thatmay be interested in participating in the financial transaction that themarket participant is proposing.

If the market participant (i.e., the initiating party) indicates (at410) that there is one or more potential counterparties that the marketparticipant is aware of that may be interested in participating in thefinancial transaction, then the platform 220 (at 412) enables the marketparticipant to identify those parties to the platform 220. This may beaccomplished, for example, by presenting, at the user interface, a formthat the market participant can fill in with identifying data and otherdata about the one or more potential counterparties.

In the example represented by the illustrated implementation, the marketparticipant identifies three potential counterparties that the marketparticipant is aware of that may be interested in participating in thefinancial transaction. In a typical implementation and, as shown, theplatform 220, when prompted, sends a Request For Quote (RFQ) (at 414 a,414 b, 414 c) to each one of the three identified potentialcounterparties. In some implementations, the RFQs are sentelectronically, for example, by email, messaging or similar means.

In the example represented by the illustrated implementation, theplatform 220 receives (at 416 a, 416 b, 416 c) offer details back fromall three of the identified counterparties.

According to the illustrated embodiment, the offer details (e.g., volumeand price quoted by each of the three respective potentialcounterparties) are conveyed to the market participant (at 418). In atypical implementation, this is accomplished by presenting the offerdetails either on a website, or in an email, or electronic message,etc., which can be accessed by the market participant (i.e., theinitiating party).

In some implementations, the platform 220 sends the RFQs confidentially(i.e., without revealing to the potential counterparties the initiatingparty's identity). This can be done automatically or, in someimplementations, the platform 220 enables the initiating party tospecify that the RFQs 414 a, 414 b, 414 c be sent anonymously. Inresponse to an initiating party's request in this regard, the platform220 sends the RFQs (at 414 a, 414 b, 414 c) to the identified potentialcounterparties anonymously (i.e., without revealing to the potentialcounterparties the initiating party's identity).

Similarly, in some implementations, the platform 220 automaticallyconveys the offer details it receives to the initiating partyanonymously (i.e., without revealing the identity of the correspondingpotential counterparty to the initiating party).

Regardless of whether the market participant (i.e., the initiatingparty) identifies (at 410) one or more potential counterparties that themarket participant is aware of that may be interested in participatingin the financial transaction, in the illustrated implementation, theplatform 220 helps the market participant to find one or more otherpotential counterparties that the market participant has not identifiedthat may be interested in participating in the financial transaction.

In a typical implementation, the platform's sales engine 362, inresponse to a prompt from the market participant, processes the detailsof the market participant's request (at 420) and engages the matchingengine 364 to identify one or more potential counterparties that arelikely to participate in the financial transaction.

Then, drawing (at 422) on relevant information contained within theplatform's knowledge base (e.g., one or more of information in theelectronic database 368, customer trade history data 352, customeralerts information 354, customer supplied data 356, system transactiondata 358, customer listed securities 360 and other data), the matchingengine 364 identifies (at 424) one or more potential counterpartiesthat, based on the information, would be likely to participate in theproposed financial transaction.

In the illustrated implementation, for each of the one or more potentialcounterparties identified, the matching engine 364 assigns confidencescores (at 426) to each respective one of the one or more potentialcounterparties identified by the matching engine. In general, theconfidence scores are intended to reflect how likely each of therespective potential counterparties is to enter into the proposedfinancial transaction. In a typical implementation, the matching enginecalculates the confidence scores by considering a number of differentcharacteristics associated with each one of the potential counterpartiesand increasing or decreasing a numeric tally for that potentialcounterparty depending on the specifics of each characteristicconsidered.

In some implementations, the matching engine 364 ranks the potentialcounterparties according to the assigned confidence scores. Informationrelated to the identified counterparties, the assigned confidence scoresand/or the top (i.e., most likely to participate) potentialcounterparties, is returned to the sales engine 362.

In the illustrated implementation, the sales engine 362 sends an RFQ (at428 a, 428 b, 428 c) to the top three potential counterparties mostlikely to participate (at 428 a, 428 b, 428 c). In some implementations,this is done automatically in response to the sales engine 362 receivinginformation identifying the top potential counterparties from thematching engine 364. However, in some implementations, the sales engine362 may prompt the initiating party for instructions in this regardbefore sending the RFQs.

In some implementations, the platform 220 sends the RFQs confidentially(i.e., without revealing to the potential counterparties the initiatingparty's identity). This can be done automatically or, in someimplementations, the platform 220 enables the initiating party tospecify if the RFQs 428 a, 428 b, 428 c be sent anonymously. In responseto an initiating party's request in this regard, the platform 220 sendsthe RFQs (at 428 a, 428 b, 428 c) to the identified potentialcounterparties anonymously (i.e., without revealing to the potentialcounterparties the initiating party's identity).

In the example represented by the illustrated implementation, theplatform 220 receives (at 430 a, 430 b, 430 c) offer details back fromall three of the potential counterparties (CP1, CP2, and CP3).

According to the illustrated implementation, the sales engine 362 (at432) receives all offer details received. This includes the offerdetails received (at 416 a, 416 b, 416 c) from the potentialcounterparties identified by the initiating party as well as the offerdetails received (at 430 a, 430 b, 430 c) from the potentialcounterparties identified by the matching engine 364.

The sales engine 362 forwards information about all of the offer detailsto the price aggregation engine 366. The price aggregation engine 366(at 434) reviews the various offer details and returns the best possibleprice (436) either from among the various offers or by combining variousoffers.

The platform 220 conveys the best possible price as determined by theprice aggregation engine, to the market participant 418 in addition tothe offer details from the requested counterparties.

FIG. 5 shows an exemplary process that may be implemented by thematching engine 364 in identifying potential counterparties andassigning confidence scores to the identified potential counterparties.

In general, when the Sales engine 362 calls the matching engine 364 toidentify potential counterparties and to assign confidence scores to theidentified potential counterparties, the matching engine implements amatching algorithm 502 that uses data in the platform's knowledge baseto assign point values for each potential counterparty based on aconsideration of various characteristics. Factors that can affect theassigned point values can include, for example, trade history of thepotential counterparty, any current bids or offers listed by thepotential counterparty for the security at issue, positions thepotential counterparty holds in the security at issue, any betterbuyer/seller signals, and any signal positions in correlated securities.The matching algorithm 402 uses these (and potentially other) factors tocalculate point values to be assigned to each potential counterparties.

In order to select the appropriate number of potential counterparties tocontact, the algorithm 502 returns a database of point values 504. Theplatform then generates a tally (at 506) of the sum of all point valuesassigned by the matching algorithm 502. Some percentage of the totalpoints assigned is then calculated (at 508) to be used as a count. Thiscount is then applied to a list of all potential counterparties ordered(at 510) from most to fewest points. Starting from the first potentialcounterparty, the system subtracts (at 512) the points assigned to thatcounterparty from the overall count. The system continues down the listof potential counterparties, subtracting the assigned values for eachparty from the count until the count is exhausted (at 514). The systemthen generates the list of potential counterparties based on thecounterparties that fell within the count and returns the selectedcounterparties and corresponding confidence scores (at 518).

Therefore, if very few of the potential counterparties have a majorityof the points, the matching engine will return few potentialcounterparties. If, however, point scores are generally low and even,the matching engine will return more counterparties, which tends tocompensate for a relative lack of available liquidity in the relevantmarket.

After calculating confidence scores (or point values) for each potentialcounterparty, the matching engine ranks all potential counterparties inorder of decreasing scores, and returns the list of potentialcounterparties with corresponding confidence scores and the number ofparties to contact at 518.

FIGS. 6A-6F show details of an exemplary method that can be implementedby the matching engine to assign points for a confidence score to apotential counterparty. In a typical implementation, the data needed toassess many, if not all, of the various characteristics discussed wouldbe available in the platforms knowledge base.

More particularly, the illustrated method includes consideration of thepotential counterparty's current bids/offers (FIG. 6A), the potentialcounterparty's quoting history (FIG. 6B), the potential counterparty'stransaction history (FIG. 6C), the potential counterparty's signaling(FIG. 6D), the potential counterparty's portfolio holdings (FIG. 6E) andinformation in the potential counterparty's virtual user's profile (FIG.6F). In some implementations, one or more of these considerations may beomitted. Similarly, in some implementations, other considerations may beadded (e.g., the time decay and/or wrong side multipliers).

In general, according to the illustrated implementation, the moreconfidence points that are assigned to a particular one of the potentialcounterparties, the more likely that particular one of the potentialcounterparties will be to complete the proposed financial transactionand, therefore, the more worthwhile that particular one of the potentialcounterparties will be to contact. In the illustrated implementation,the matching engine 364 maintains a running tally of confidence pointsassigned throughout the process represented in FIGS. 6A-6F.

Referring now to FIG. 6A, the matching engine considers, based on datain the platform's knowledge base, the potential counterparty'sinvolvement in current bids or offers related to the fixed incomesecurity or securities that is or are the subject of the proposedfinancial transaction (referred to herein as the “fixed income securityin question”).

According to the illustrated implementation, the matching engine (at602) determines, based on the data in the electronic database, to whatdegree the potential counterparty is involved in a current bid or offerfor the fixed income security within the order book or has a current RFQin the marketplace. If so, the matching engine “auto pings” (i.e.,automatically sends the potential counterparty a request for quotation,at 604, 606). If not, the matching engine proceeds to the next step inthe illustrated process.

Next, the matching engine (at 608) determines, based on the data in theelectronic database, to what degree the potential counterparty isinvolved in a current bid for a different fixed income security with thesame issuer as the fixed income security. If the potential counterpartyhas placed an order for a different fixed income security with the sameissuer as the fixed income security in question, then, according to theillustrated embodiment, the matching engine (at 610) adds 1,000 pointsto the running tally of assigned confidence points. If the potentialcounterparty has a request for quotation outstanding for the differentfixed income security with the same issuer as the fixed income securityin question, then, according to the illustrated embodiment, the matchingengine (at 612) adds 980 points to the running tally of assignedconfidence points. The matching engine then proceeds to the next step inthe illustrated process.

Next, the matching engine (at 614) determines, based on the data in theelectronic database, to what degree the potential counterparty isinvolved in a current bid for a different fixed income security in thesame industry as the fixed income security. If the potentialcounterparty has placed an order for a different fixed income securityin the same industry as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 616)adds 600 points to the running tally of assigned confidence points. Ifthe potential counterparty has a request for quotation outstanding for adifferent fixed income security in the same industry as the fixed incomesecurity in question, then, according to the illustrated embodiment, thematching engine (at 618) adds 580 points to the running tally ofassigned confidence points.

In general, with respect to historical transactions, a counterparty mayhave transacted more than one time in a bond, for example, fitting thecriteria being checked. For example, a counterparty may have traded theCUSIP in question yesterday, last week and last year. To properly creditthis user, in a typical implementation, it is assumed that every checkpoint will be exhausted using all available and historic information.Thus, the various categories of considerations discussed herein shouldbe circled around until all historic information on record has beenaccounted for. In general, time decay factors should be adapted toprovide proper weighting to older transactions.

Moreover, as illustrated, several stages of the algorithm have loopsimplemented to ensure that all securities have been exhausted at therelevant levels (see, e.g., 608 a, 614 a, 620 a, 626 a and 632 a).

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 620) determines, based on the data in theelectronic database, to what degree the potential counterparty isinvolved in a current bid for a different fixed income security in thesame maturity bracket as the fixed income security. If the potentialcounterparty has placed an order for a different fixed income securityin the same maturity bracket as the fixed income security in question,then, according to the illustrated embodiment, the matching engine (at622) adds 130 points to the running tally of assigned confidence points.If the potential counterparty has a request for quotation outstandingfor a different fixed income security in the same industry as the fixedincome security in question, then, according to the illustratedembodiment, the matching engine (at 624) adds 120 points to the runningtally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 626) determines, based on the data in theelectronic database, to what degree the potential counterparty isinvolved in a current bid for a different fixed income security with thesame rating as the fixed income security. If the potential counterpartyhas placed an order for a different fixed income security with the samerating as the fixed income security in question, then, according to theillustrated embodiment, the matching engine (at 628) adds 90 points tothe running tally of assigned confidence points. If the potentialcounterparty has a request for quotation outstanding for a differentfixed income security with the same rating as the fixed income securityin question, then, according to the illustrated embodiment, the matchingengine (at 630) adds 80 points to the running tally of assignedconfidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 632) determines, based on the data in theelectronic database, to what degree the potential counterparty isinvolved in a current bid for a different fixed income security with thesame yield percentage as the fixed income security in question. If thepotential counterparty has placed an order for a different fixed incomesecurity with the same yield percentage as the fixed income security inquestion, then, according to the illustrated embodiment, the matchingengine (at 634) adds 90 points to the running tally of assignedconfidence points. If the potential counterparty has a request forquotation outstanding for a different fixed income security with thesame yield percentage as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 636)adds 80 points to the running tally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Referring now to FIG. 6B, the matching engine considers, based on datain the platform's knowledge base, the potential counterparty's quotinghistory as it relates to the fixed income security (or securities) thatis the subject of the proposed financial transaction.

According to the illustrated implementation, the matching engine (at638) determines, based on the data in the electronic database, to whatdegree the potential counterparty has ever been involved in a past bidor offer for the fixed income security. If the potential counterpartyhas placed a past order for the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 640)adds 750 points (minus a factor representing the elapsed time asmodified by a time decay multiplier) to the running tally of assignedconfidence points. If the potential counterparty has had a past requestfor quotation for the fixed income security in question, then, accordingto the illustrated embodiment, the matching engine (at 642) adds 725points (minus a factor representing the elapsed time as modified by atime decay multiplier) to the running tally of assigned confidencepoints.

In some implementations, the factor representing the elapsed time may bethe total number of seconds, minutes, hours and/or days elapsed and thetime decay multiplier can be any number that represents the relativeimpact that the passage of time will have on the relevance of aparticular type of past dealings.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 644) determines, based on the data in theelectronic database, to what degree the potential counterparty wasinvolved in a past bid for a different fixed income security with thesame issuer as the fixed income security. If the potential counterpartyhas placed a past order for a different fixed income security with thesame issuer as the fixed income security in question, then, according tothe illustrated embodiment, the matching engine (at 646) adds 200 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has had a past request for quotation for adifferent fixed income security with the same issuer as the fixed incomesecurity the fixed income security in question, then, according to theillustrated embodiment, the matching engine (at 648) adds 175 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 650) determines, based on the data in theelectronic database, to what degree the potential counterparty wasinvolved in a past bid for a different fixed income security in the sameindustry as the fixed income security. If the potential counterparty hasplaced a past order for a different fixed income security in the sameindustry as the fixed income security in question, then, according tothe illustrated embodiment, the matching engine (at 652) adds 100 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has had a past request for quotation for adifferent fixed income security in the same industry as the fixed incomesecurity in question, then, according to the illustrated embodiment, thematching engine (at 654) adds 75 points (minus a factor representing theelapsed time as modified by a time decay multiplier) to the runningtally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 656) determines, based on the data in theelectronic database, to what degree the potential counterparty wasinvolved in a past bid for a different fixed income security in the samematurity bracket as the fixed income security. If the potentialcounterparty has placed a past order for a different fixed incomesecurity in the same maturity bracket as the fixed income security inquestion, then, according to the illustrated embodiment, the matchingengine (at 658) adds 50 points (minus a factor representing the elapsedtime as modified by a time decay multiplier) to the running tally ofassigned confidence points. If the potential counterparty has had a pastrequest for quotation for a different fixed income security in the samematurity bracket as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 660)adds 25 points (minus a factor representing the elapsed time as modifiedby a time decay multiplier) to the running tally of assigned confidencepoints.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 662) determines, based on the data in theelectronic database, to what degree the potential counterparty wasinvolved in a past bid for a different fixed income security with thesame rating as the fixed income security. If the potential counterpartyhas placed a past order for a different fixed income security with thesame rating as the fixed income security in question, then, according tothe illustrated embodiment, the matching engine (at 664) adds 20 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has had a past request for quotation for adifferent fixed income security with the same rating as the fixed incomesecurity in question, then, according to the illustrated embodiment, thematching engine (at 666) adds 10 points (minus a factor representing theelapsed time as modified by a time decay multiplier) to the runningtally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 668) determines, based on the data in theelectronic database, to what degree the potential counterparty wasinvolved in a past bid for a different fixed income security with thesame yield percentage as the fixed income security. If the potentialcounterparty has placed a past order for a different fixed incomesecurity with the same yield percentage as the fixed income security inquestion, then, according to the illustrated embodiment, the matchingengine (at 670) adds 20 points (minus a factor representing the elapsedtime as modified by a time decay multiplier) to the running tally ofassigned confidence points. If the potential counterparty has had a pastrequest for quotation for a different fixed income security with thesame yield percentage as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 672)adds 10 points (minus a factor representing the elapsed time as modifiedby a time decay multiplier) to the running tally of assigned confidencepoints.

The matching engine then proceeds to the next step in the illustratedprocess.

Referring now to FIG. 6C, the matching engine considers, based on datain the platform's knowledge base, the potential counterparty'stransaction history for actual completed transactions as they relates tothe fixed income security (or securities) that is the subject of theproposed financial transaction.

In general, with respect to historical transactions, a counterparty mayhave transacted more than one time in a bond, for example, fitting thecriteria being checked. For example, a counterparty may have traded theCUSIP in question yesterday, last week and last year. To properly creditthis user, in a typical implementation, it is assumed that every checkpoint will be exhausted using all available and historic information.Thus, the various categories of considerations discussed herein shouldbe circled around until all historic information on record has beenaccounted for. In general, the time decay factors should be adapted toprovide proper weighting to older transactions.

According to the illustrated implementation, the matching engine (at674) determines, based on the data in the electronic database, to whatdegree the potential counterparty has completed a transaction includingthe fixed income security. If the potential counterparty has bought thefixed income security in question, then, according to the illustratedembodiment, the matching engine (at 676) adds 1,500 points (minus afactor representing the elapsed time as modified by a time decaymultiplier) to the running tally of assigned confidence points. If thepotential counterparty has sold the fixed income security in question,then, according to the illustrated embodiment, the matching engine (at678) adds some different number of points (times a wrong side multiplierand minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points.

In a typical implementation, the wrong side multiplier is a numberbetween zero and 1 and that adjusts the impact of the counterparty'sinvolvement in the particular transaction in view of the fact that itwas the seller when a buyer is sought.

Next, the matching engine (at 680) determines, based on the data in theelectronic database, to what degree the potential counterparty hascompleted a transaction including a different fixed income security withthe same issuer as the fixed income security. If the potentialcounterparty has bought a different fixed income security with the sameissuer as the fixed income security in question, then, according to theillustrated embodiment, the matching engine (at 682) adds 1,000 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has sold a different fixed income securitywith the same issuer as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 684)adds some number of points (times a wrong side multiplier, minus afactor representing the elapsed time as modified by a time decaymultiplier) to the running tally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 686) determines, based on the data in theelectronic database, to what degree the potential counterparty hascompleted a transaction including a different fixed income security inthe same industry as the fixed income security. If the potentialcounterparty has bought a different fixed income security in the sameindustry as the fixed income security in question, then, according tothe illustrated embodiment, the matching engine (at 688) adds 600 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has sold a different fixed income security inthe same industry as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 690)adds some number of points (times a wrong side multiplier, minus afactor representing the elapsed time as modified by a time decaymultiplier) to the running tally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 692) determines, based on the data in theelectronic database, to what degree the potential counterparty hascompleted a transaction including a different fixed income security inthe same maturity bracket as the fixed income security. If the potentialcounterparty has bought a different fixed income security in the samematurity bracket as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 694)adds 130 points (minus a factor representing the elapsed time asmodified by a time decay multiplier) to the running tally of assignedconfidence points. If the potential counterparty has sold a differentfixed income security in the same maturity bracket as the fixed incomesecurity in question, then, according to the illustrated embodiment, thematching engine (at 696) adds some number of points (times a wrong sidemultiplier, minus a factor representing the elapsed time as modified bya time decay multiplier) to the running tally of assigned confidencepoints.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 698) determines, based on the data in theelectronic database, to what degree the potential counterparty hascompleted a transaction including a different fixed income security withthe same rating as the fixed income security. If the potentialcounterparty has bought a different fixed income security with the samerating as the fixed income security in question, then, according to theillustrated embodiment, the matching engine (at 601) adds 90 points(minus a factor representing the elapsed time as modified by a timedecay multiplier) to the running tally of assigned confidence points. Ifthe potential counterparty has sold a different fixed income securitywith the same rating as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 603)adds some number of points (times a wrong side multiplier, minus afactor representing the elapsed time as modified by a time decaymultiplier) to the running tally of assigned confidence points.

The matching engine then proceeds to the next step in the illustratedprocess.

Next, the matching engine (at 605) determines, based on the data in theelectronic database, to what degree the potential counterparty hascompleted a transaction including a different fixed income security withthe same yield percentage as the fixed income security. If the potentialcounterparty has bought a different fixed income security with the sameyield percentage as the fixed income security in question, then,according to the illustrated embodiment, the matching engine (at 607)adds 90 points (minus a factor representing the elapsed time as modifiedby a time decay multiplier) to the running tally of assigned confidencepoints. If the potential counterparty has sold a different fixed incomesecurity with the same yield percentage as the fixed income security inquestion, then, according to the illustrated embodiment, the matchingengine (at 609) adds some number of points (times a wrong sidemultiplier, minus a factor representing the elapsed time as modified bya time decay multiplier) to the running tally of assigned confidencepoints.

The matching engine then proceeds to the next step in the illustratedprocess.

Referring now to FIG. 6D, the matching engine considers, based on datain the platform's knowledge base, the potential counterparty's signalingthat may be relevant to the fixed income security (or securities) thatis the subject of the proposed financial transaction.

The matching engine checks (at 611) to what degree the counterparty hasindicated a level of interest in dealing with the fixed income security.If they have, then the system adds points to the running tally ofassigned confidence points based on to what degree the party is a betterbuyer (in 613, 637) or seller (in 615 or 639) and the quantity theytrade in. Any points assigned are adjusted by a wrong side multiplier,if the indication or tendency of the party is for the opposite side ofthe transaction.

The matching engine checks (at 617) for indications relevant to thefixed income security in dealer run emails and/or axe sheets. In someimplementations, the emails and axe sheets are parsed by a differentsystem, and the results are stored in the platform's knowledge base. Thematching engine, in a typical implementation, treats these indicationsmuch like the “likes” of the previous loop. The system also checksdifferent types of alerts (at 627) created by the counterparty, as wellas watch lists (at 633) created by the counterparty. Appropriate pointsare added (at 619, 621, 623, 625, 629, 631 and 635) to the running tallyof assigned confidence points as indicated. In various implementations,any one or more of these checks can be modified by a time decaymultiplier.

In some implementations, the checks illustrated in FIG. 6 d are repeatedat different levels and with different point values for issuer, sector,rating, maturity, yield, and any other aspect of the security searchedfor.

Referring now to FIG. 6E, the matching engine considers, based on datain the platform's knowledge base, the potential counterparty's portfolioholdings as they relate to the fixed income security (or securities)that is the subject of the proposed financial transaction.

According to the illustrated implementation, the matching engine (at641) determines, based on the data in the electronic database, to whatdegree the potential counterparty has the fixed income security in itsportfolio holdings. If so, then, according to the illustratedembodiment, the matching engine (at 643) adds 500 points to the runningtally of assigned confidence points. Moreover, depending on the size ofthe holdings, the matching engine (at 645) adds an additional 100 (timesthe size of the holdings as compared to the RFQ quantity, as apercentage).

The annotation “+o for no size” indicates that if there is no size held,then the loop adds zero. Similar marks exist in other iterations in theflowchart.

Next, the matching engine (at 647) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security with the same issuer as the fixed incomesecurity in question in its portfolio holdings. If so, then, accordingto the illustrated embodiment, the matching engine (at 649) adds 300points to the running tally of assigned confidence points. Moreover,depending on the size of the holdings, the matching engine (at 651) addsan additional 80 points (times the size of the holdings as compared tothe RFQ quantity, as a percentage).

Next, the matching engine (at 653) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security in the same industry as the fixed incomesecurity in question. If so, then, according to the illustratedembodiment, the matching engine (at 655) adds 200 points to the runningtally of assigned confidence points. Moreover, depending on the size ofthe holdings, the matching engine (at 657) adds an additional 60 points(times the size of the holdings as compared to the RFQ quantity, as apercentage).

Next, the matching engine (at 653) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security in the same industry as the fixed incomesecurity in question. If so, then, according to the illustratedembodiment, the matching engine (at 655) adds 200 points to the runningtally of assigned confidence points. Moreover, depending on the size ofthe holdings, the matching engine (at 657) adds an additional 60 points(times the size of the holdings as compared to the RFQ quantity, as apercentage).

Next, the matching engine (at 659) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security in the same maturity bracket as thefixed income security in question. If so, then, according to theillustrated embodiment, the matching engine (at 661) adds 50 points tothe running tally of assigned confidence points. Moreover, depending onthe size of the holdings, the matching engine (at 663) adds anadditional 20 points (times the size of the holdings as compared to theRFQ quantity, as a percentage).

Next, the matching engine (at 665) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security with the same rating as the fixed incomesecurity in question. If so, then, according to the illustratedembodiment, the matching engine (at 667) adds 25 points to the runningtally of assigned confidence points. Moreover, depending on the size ofthe holdings, the matching engine (at 669) adds an additional 10 points(times the size of the holdings as compared to the RFQ quantity, as apercentage).

Next, the matching engine (at 671) determines, based on the data in theelectronic database, to what degree the potential counterparty has adifferent fixed income security with the same percent yield as the fixedincome security in question. If so, then, according to the illustratedembodiment, the matching engine (at 673) adds 25 points to the runningtally of assigned confidence points. Moreover, depending on the size ofthe holdings, the matching engine (at 675) adds an additional 10 points(times the size of the holdings as compared to the RFQ quantity, as apercentage).

Referring now to FIG. 6F, the matching engine considers to what degree avirtual profile set up by the potential counterparty reflects aninterest in the CUSIP (at 677), an interest in the issuer (at 679), aninterest in the industry (at 681), an interest in the maturity bracket(at 683), an interest in the rating (at 685) and an interest in thepercent yield (at 687). For each positive indication, the matchingengine adds (at 695, 697, 699, 702, 704 and 706) a corresponding numberof points to the running tally of assigned confidence points.

The matching engine also considers to what degree the potentialcounterparty is a dealer (at 689), an asset manager (at 691) or a hedgefund (at 693). If so, the matching engine considers to what degree thepotential counterparty is looking for a seller or looking for a buyerand adds (at 708, 710, 712, 714, 716 and 718) a corresponding number ofpoints to the running tally of assigned confidence points.

In a typical implementation, the running tally (and final tally) ofassigned confidence points for each of the potential counterpartiesconsidered, is stored 719 in the electronic database.

FIGS. 7A-7F are schematic representations of the various specificinteractions.

Referring now to FIG. 7A, the platform 220 sends an RFQ to threepotential counterparties 901 (CP-1, CP-2, CP-3) that have beenidentified by an initiating party (“Trader A”). In the illustratedimplementation, the RFQ is for 2 million units of a particular fixedincome security. The sales engine 362 also receives an indication thatquotations are desired.

According to the illustrated implementation, all three potentialcounterparties identified by the initiating party respond to the RFQwith offers that include a size and price. For example, potentialcounterparty CP-1 responds with an offer to buy 2 million units at$100.00 per unit, potential counterparty CP-2 responds with an offer tobuy 2 million units at $100.10 per unit and potential counterparty CP-3responds with an offer to buy 2 million units at $99.75 per unit.

In the illustrated implementation, the platform 220 makes each of thethree offers returned by initiating party-selected potentialcounterparties (CP-1, CP-2, CP-3) available for viewing at a visualdisplay 908 of a computer terminal that is accessible by the initiatingparty.

The sales engine 362, in response to receiving the indication thatquotations are desired, engages the matching engine 364 to find one ormore potential counterparties that are likely, based on information inthe platform's knowledge base, to be interested in responding to the RFQ(and completing the proposed financial transaction associated with theRFQ).

The matching engine 364 returns three potential counterparties 903(CP-4, CP-5, CP-6) and the platform 220 sends the RFQ to the threematching engine-identified, potential counterparties (CP-4, CP-5, CP-6).

According to the illustrated implementation, all three of thematching-engine-identified, potential counterparties (CP-4, CP-5, andCP-6) respond to the RFQ with an offer specifying size and price. Forexample, potential counterparty CP-4 responds with an offer to buy 2million units at $100.00 per unit, potential counterparty CP-5 respondswith an offer to buy 2 million units at $99.50 per unit and potentialcounterparty CP-6 responds with an offer to buy 2 million units at$99.60 per unit.

The sales engine (at 910) receives all three offers from the matchingengine-identified potential counterparties. The sales engine ranks theoffers from best to worst and identifies the best of the offers, whichin the illustrated example is the offer of 2 million units at $99.50received from potential counterparty CP-5.

According to the illustrated implementation, the platform 220 makes thebest of the three offers returned by the matching-engine-identifiedpotential counterparties (in this case CP-5's offer) available forviewing at a visual display 908 of a computer terminal that isaccessible by the initiating party. In a typical implementation, this isdone anonymously, that is without revealing to the initiating party theresponding counterparty's identity.

FIG. 7B is similar to FIG. 7A, in that the three potentialcounterparties 901 selected by the initiating party and the threematching engine-selected potential counterparties 903 are sent RFQs.Moreover, all of those parties respond with quotes 905, 906 whichcontain both size and price. However, in the example of FIG. 7B, theinitiating party (“client 1”) has requested to buy 2 million units at908 and each of the counterparty offers with the best prices (i.e., theoffer from CP-5 for 1 million units at $99.50 and the offer from CP-6for 1 million at $99.60) is too small to satisfy the requirements of theinitiating party (“client 1”).

Therefore, in the illustrated implementation, the sales engine,recognizing that neither one of the best offers received from thematching engine-selected potential counterparties would satisfy theinitiating party's requirements on its own, uses the price aggregationengine to combine the two best offers into a single offer having a pricethat is a weighted average of the two best prices. In the illustratedexample, the two best offers (i.e., the offer from CP-5 for 1 millionunits at $99.50 and the offer from CP-6 for 1 million at $99.60) arecombined into a single offer for 2 million units at $99.55 that is madeavailable for viewing to the initiating party.

In the illustrated example, the single offer that represents the twobest offers from matching engine-selected potential counterparties isthe best of all of the offers presented to the initiating party.

FIG. 7C is similar to FIG. 7 b, except that the best price in the offersreceived appears in an offer from one of the potential counterparties(CP-3) selected by the initiating party and in an offer received fromone of the potential counterparties (CP-5) selected by the matchingengine. Each of those offers is for 1 million units at $99.50 per unit.

In FIG. 7C, the initiating party's request is for 2 million units.Therefore, each of the offers with the best price is too small on itsown to satisfy the 2 million unit requirement. Accordingly, in theillustrated implementation, the aggregation engine combines the twooffers having the best price (i.e., the offer for 1 million units at$99.50 from CP-3 and the offer for 1 million units at $99.50 from CP-5)into a single offer for 2 million units at $99.50 that is made availablefor viewing to the initiating party. The sales engine 902, in thisexample, applies the aggregation engine over all available quotes andreturns the best possible single aggregated quote 907 for the userrequested volume.

In a typical implementation, this is reported alongside all quotesreturned by the initiating party-selected counterparties including thequote included in the aggregated result.

FIG. 7D is similar to FIG. 7C except that the aggregation engine in FIG.7D combines offers from three different potential counterparties tosatisfy the initiating party's requirements. This includes a partialfill from one of the counterparties.

FIG. 7E is similar to FIG. 7D except that, in FIG. 7E, several of thebest prices are limited by an all-or-nothing (AON) restraint. In theillustrated implementation, the aggregation engine factors thisrestraint into its best price, and returns the best possible aggregatedprice to the trader. This price includes the worst available price for alimited portion of the order, because it is the only price availablewithout the all-or-nothing constraint. When combined with the bestavailable price, the aggregated price remains better than any otheravailable price for the requested volume.

FIGS. 7F and 7G combine to show the results of time based restraints.When the sales engine receives quotes with attached time restraints, theaggregation engine returns the best available price for the requestedquantity along with a timer counting down how long that price is goodfor. If the user does not select the quote within the time frame thequote is available for, the aggregation engine calculates a new bestavailable quote based on remaining available quotes and presents the newbest available quote to the initiating party for acceptance.

In FIG. 7F, for example, the platform 220 sends an RFQ to threepotential counterparties 901 (CP-1, CP-2, CP-3) that have beenidentified by an initiating party (“Client 1”). In the illustratedimplementation, the RFQ is for 2.5 million units of a particular fixedincome security. The sales engine 362 also receives an indication thatquotations are desired.

According to the illustrated implementation, all three potentialcounterparties identified by the initiating party respond to the RFQwith offers that include a size and price. Each of these offers has anassociated duration, beyond which the offer will expire. For example,potential counterparty CP-1 responds with an all-or-nothing offer tosell 2.5 million units at $100.00 per unit that will expire in 10seconds, potential counterparty CP-2 responds with an offer to sell 2.5million units at $100.10 per unit that will expire in 30 seconds andpotential counterparty CP-3 responds with an all-or-nothing offer tosell 1 million units at $99.50 per unit that will expire in 15 seconds.The durations are indicated by the respective potential counterparties.

In the illustrated implementation, the platform 220 makes informationassociated with each of the three offers returned by initiatingparty-selected potential counterparties (CP-1, CP-2, CP-3) available forviewing at a visual display 908 of a computer terminal that isaccessible by the initiating party. In particular, the information madeavailable in connection with these offers includes the respondingpotential counterparties' identity, the offer size and price, as well asany other relevant details (e.g., if the offer specifiesall-or-nothing). Also made available is the duration (or remainingduration, represented by a countdown-to-expiration clock, at 999)associated with each offer.

The sales engine 362, in response to receiving the indication thatquotations are desired, engages the matching engine to find one or morepotential counterparties that are likely, based on information in theplatform's knowledge base, to be interested in responding to the RFQ(and completing the proposed financial transaction associated with theRFQ).

The matching engine returns three potential counterparties 903 (CP-4,CP-5, CP-6) and the platform 220 sends the RFQ to the three potentialcounterparties identified by the matching engine (CP-4, CP-5, CP-6).

According to the illustrated implementation, all three of thematching-engine-identified potential counterparties (CP-4, CP-5, andCP-6) respond to the RFQ with an offer specifying size, price andduration. For example, potential counterparty CP-4 responds with anall-or-nothing offer to sell 1.5 million units at $100.00 per unit thatexpires in 25 seconds, potential counterparty CP-5 responds with anall-or-nothing offer to sell 2 million units at $99.50 per unit thatexpires in 17 seconds and potential counterparty CP-6 responds with anall-or-nothing offer to sell 2 million units at $99.60 per unit thatexpires in 8 seconds.

The sales engine (at 910) identifies, from among all of the offersreceived, the best combination of offers that would satisfy all of therequirements of the RFQ. In the illustrated embodiment, the sales enginecombines part of the offer from potential counterparty CP-2 with thefull offer from potential counterparty CP-5 as indicated. Moreparticularly, the sales engine combines 0.5 million units from the 2.5million at $100.10 per unit offer from CP-2 with the entire 2 millionunit all-or-nothing offer at $99.50 from CP-5. This represents the bestcombination of offers from a cost perspective for the initiating party.

In the illustrated implementation, this combined offer of 2.5 millionunits at a weighted average price of $99.62 per unit is made availablefor viewing to the initiating party in addition to the three offers fromthe potential counterparties (CP-1, CP-2, CP-3) identified by theinitiating party.

Since the offer from CP-2 has a duration of 30 seconds and the offerfrom CP-5 has a duration of 17 seconds, the duration of the combinedoffer (based on CP-2's offer and CP-5's offer) is 17 seconds (i.e., thelower duration of the offers combined). In the illustratedimplementation, the sales engine makes this 17 second duration availableto the initiating party for viewing (see 999) in association with thecombined offer details.

After the duration of 17 seconds (in FIG. 7F) expires, the combinedoffer disappears. In some implementations, this is replaced by a newoffer that is calculated based on the best of the remaining (i.e., notexpired) offers.

FIG. 7G represents the scenario of FIG. 7F after 17 seconds has expired.As illustrated, the offers from potential counterparties CP-1, CP-3,CP-5 and CP-6, having durations of 10 seconds, 15 seconds, 17 secondsand 8 seconds, respectively, are all expired (as indicated by the “Xs”).Also expired is the original combined offer (from CP-2 and CP-5), which,as discussed above, had a duration of 17 seconds.

In response to the original combined offer expiring, the sales enginerecalculates a new combination of offers that collectively provide tothe initiating party the best price available for the requested quantitybased on the offers that have not yet expired. In the illustratedexample, the new best offer is 2.5 million units at $100.04 per unitwith a duration of 8 seconds. This is based on combining 1 million unitsfrom CP-2's 2.5 million unit offer at $100.10 per unit and having aduration of 13 seconds with the 1.5 million unit all-or-nothing offerfrom CP-4 for 1.5 million units for $100.00 per unit having a durationof 8 seconds.

The best new combined offer is made available for viewing to theinitiating party.

In a typical implementation, the best combined offer presented toinitiating party can continue to change as the contributors to theprevious best combined offers expire and as long as unexpired offersremain.

FIGS. 8A-8F are exemplary screenshots that an initiating party may seewhen accessing certain aspects of the platform's functionality asdiscussed herein.

FIG. 8A, for example, includes a list 802 of bonds that the initiatingparty can select among to have RFQs sent out to one or more potentialcounterparties. In the illustrated screenshot, the line associated with(GE 4.375 09/20) is marked in a manner indicating that (GE 4.375 09/20)is being selected by the initiating party. A variety of otherinformation is provided on this screen as well.

Referring now to FIG. 8B, when the initiating party selects (GE 4.37509/20), a dialog box 804 opens, in which the initiating party can selectone or more specific counterparties as well as other information, asindicated, that may be relevant to the proposed transaction.

In FIG. 8C, the initiating party is shown in box 806 a proposed tradewith a potential counterparty. In some implementations, this box 806shows the best proposed trades as they are submitted, and if applicable,with the time remaining at 808 to accept each proposal.

FIG. 8D shows the final trade proposal 810 offered to the initiatingparty, which can be accepted (by clicking the check 812) or rejected (byclicking the “x” 814).

FIG. 8E provides a trade confirmation box 816 that appears if the finaltrade proposal is accepted by the initiating party. The illustratedtrade confirmation box 816 confirms various details of the transaction.The confirmation typically will identify the system administrator as thecounterparty, a riskless principal, and maintain the anonymity of thecounterparty to the financial transaction.

FIG. 8F shows an example of a screenshot that enables the initiatingparty, for example, to selecting preferences. This includes profilepieces that are used in the functionality disclosed herein.

A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention.

For example, the specific appearance of the screenshots can varyconsiderably.

Additionally, certain aspects of the functionality disclosed can beperformed without a computer.

The specific data collected and analyzed in connection with the variousfunctions disclosed herein can differ from what is explicitly disclosed.For example, in some implementations, other factors beyond thoseexplicitly disclosed herein may be considered in assigning confidencescores to the potential counterparties. Similarly, in someimplementations, fewer factors may be considered.

Likewise, the points added and corresponding weighting factors used incalculating the confidence scores may differ from those explicitlydisclosed herein.

In some implementations, the order book functionality disclosed hereinmay be omitted or performed by an entirely separate system.

Embodiments of the subject matter and the operations described in thisspecification can be implemented in digital electronic circuitry, or incomputer software, firmware, or hardware, including the structuresdisclosed in this specification and their structural equivalents, or incombinations of one or more of them. Embodiments of the subject matterdescribed in this specification can be implemented as one or morecomputer programs, i.e., one or more modules of computer programinstructions, encoded on computer storage medium for execution by, or tocontrol the operation of, data processing apparatus. Alternatively or inaddition, the program instructions can be encoded on anartificially-generated propagated signal, e.g., a machine-generatedelectrical, optical, or electromagnetic signal that is generated toencode information for transmission to suitable receiver apparatus forexecution by a data processing apparatus. A computer storage medium canbe, or be included in, a computer-readable storage device, acomputer-readable storage substrate, a random or serial access memoryarray or device, or a combination of one or more of them. Moreover,while a computer storage medium is not a propagated signal, a computerstorage medium can be a source or destination of computer programinstructions encoded in an artificially-generated propagated signal. Thecomputer storage medium can also be, or be included in, one or moreseparate physical components or media (e.g., multiple CDs, disks, orother storage devices).

The operations described in this specification can be implemented asoperations performed by a data processing apparatus on data stored onone or more computer-readable storage devices or received from othersources.

The term “data processing apparatus” and like terms encompass all kindsof apparatus, devices, and machines for processing data, including byway of example a programmable processor, a computer, a system on a chip,or multiple ones, or combinations, of the foregoing. The apparatus caninclude special purpose logic circuitry, e.g., an FPGA (fieldprogrammable gate array) or an ASIC (application-specific integratedcircuit). The apparatus can also include, in addition to hardware, codethat creates an execution environment for the computer program inquestion, e.g., code that constitutes processor firmware, a protocolstack, a database management system, an operating system, across-platform runtime environment, a virtual machine, or a combinationof one or more of them. The apparatus and execution environment canrealize various different computing model infrastructures, such as webservices, distributed computing and grid computing infrastructures.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, object, orother unit suitable for use in a computing environment. A computerprogram may, but need not, correspond to a file in a file system. Aprogram can be stored in a portion of a file that holds other programsor data (e.g., one or more scripts stored in a markup languagedocument), in a single file dedicated to the program in question, or inmultiple coordinated files (e.g., files that store one or more modules,sub-programs, or portions of code). A computer program can be deployedto be executed on one computer or on multiple computers that are locatedat one site or distributed across multiple sites and interconnected by acommunication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform actions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit).

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor will receive instructions and data from a read-only memory ora random access memory or both. The essential elements of a computer area processor for performing actions in accordance with instructions andone or more memory devices for storing instructions and data. Generally,a computer will also include, or be operatively coupled to receive datafrom or transfer data to, or both, one or more mass storage devices forstoring data, e.g., magnetic, magneto-optical disks, or optical disks.However, a computer need not have such devices. Moreover, a computer canbe embedded in another device, e.g., a mobile telephone, a personaldigital assistant (PDA), a mobile audio or video player, a game console,a Global Positioning System (GPS) receiver, or a portable storage device(e.g., a universal serial bus (USB) flash drive), to name just a few.Devices suitable for storing computer program instructions and datainclude all forms of non-volatile memory, media and memory devices,including by way of example semiconductor memory devices, e.g., EPROM,EEPROM, and flash memory devices; magnetic disks, e.g., internal harddisks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROMdisks. The processor and the memory can be supplemented by, orincorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a computerhaving a display device, e.g., a CRT (cathode ray tube) or LCD (liquidcrystal display) monitor, for displaying information to the user and akeyboard and a pointing device, e.g., a mouse or a trackball, by whichthe user can provide input to the computer. Other kinds of devices canbe used to provide for interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user can be received in any form, including acoustic, speech, ortactile input. In addition, a computer can interact with a user bysending documents to and receiving documents from a device that is usedby the user; for example, by sending web pages to a web browser on auser's client device in response to requests received from the webbrowser.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back-end component.e.g., as a data server, or that includes a middleware component, e.g.,an application server, or that includes a front-end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back-end, middleware, or front-end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), an inter-network (e.g., the Internet), andpeer-to-peer networks (e.g., ad hoc peer-to-peer networks).

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. In someembodiments, a server transmits data (e.g., an HTML page) to a clientdevice (e.g., for purposes of displaying data to and receiving userinput from a user interacting with the client device). Data generated atthe client device (e.g., a result of the user interaction) can bereceived from the client device at the server.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinventions or of what may be claimed, but rather as descriptions offeatures specific to particular embodiments of particular inventions.Certain features that are described in this specification in the contextof separate embodiments can also be implemented in combination in asingle embodiment. Conversely, various features that are described inthe context of a single embodiment can also be implemented in multipleembodiments separately or in any suitable subcombination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asubcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems cangenerally be integrated together in a single software product orpackaged into multiple software products.

Thus, particular embodiments of the subject matter have been described.Other embodiments are within the scope of the following claims. In somecases, the actions recited in the claims can be performed in a differentorder and still achieve desirable results. In addition, the processesdepicted in the accompanying figures do not necessarily require theparticular order shown, or sequential order, to achieve desirableresults. In certain implementations, multitasking and parallelprocessing may be advantageous.

Accordingly, other implementations are within the scope of the claims.

What is claimed:
 1. A computer-based method for processing offersreceived from a plurality of potential counterparties to engage in aproposed financial transaction involving a transfer of a fixed incomesecurity, wherein the plurality of potential counterparties comprisesone or more potential counterparties specifically identified by aninitiating party as a potential counterparty to the financialtransaction and one or more potential counterparties selected by acomputer-based matching engine as likely being interested in theproposed financial transaction, the computer-based method comprising:receiving one or more offers from the potential counterpartiesspecifically identified by the initiating party; receiving one or moreoffers from the potential counterparties selected by the computer-basedmatching engine; and identifying, among the received offers, one or moreof the received offers that alone or collectively provide the initiatingparty a best price for a quantity of the fixed income security thatsatisfies requirements of the proposed financial transaction.
 2. Thecomputer-based method of claim 1 further comprising: enabling theinitiating party to access information about the one or more receivedoffers that alone or collectively provide the initiating party the bestprice for the quantity of the fixed income security that satisfiesrequirements of the proposed financial transaction.
 3. Thecomputer-based method of claim 2 wherein more than one of the receivedoffers is combined to collectively satisfy the requirements of theproposed financial transaction.
 4. The computer-based method of claim 3wherein at least one of the more than one received offers combined tosatisfy the requirements of the proposed financial transaction has anassociated duration, after which the at least one offer will expire, andwherein the information about the received offers that the initiatingparty can access is updated upon expiration of the associated durationto reflect a new best price for the quantity of the fixed incomesecurity that satisfies requirements of the proposed financialtransaction.
 5. The computer-based method of claim 4 further comprising:receiving an indication of the associated duration along with anassociated one of the received offers from one of the potentialcounterparties being combined to satisfy the requirements of theproposed financial transaction.